<relationships> <relationship name="Persists On"> <source type="JMQ JMS Queue" cardinality="one" unique="true"/> <target type="Datasource" cardinality="one"/> </relationship> <relationships>
RHQ currently has a strictly hierarchical parent-child relationship model. This design is to enhance this model to allow additional types of inventory relationships to be stored and modeled. These relationships will be specific to the resources implementing them and therefore need to be customizable, but there are some higher level relationship concepts that this system should allow the developer to adhere to for potential abstract coordination. Additionally, some dependencies will be between resources from different plugins and those would need to be of a more abstract form.
E.g. JMS Queues can utilized Datasource resources as their persistence system. A specific dependency type can be built that combines the types and the dependency into a three part system, source, dependency types and destination. This example would be "JMS Queue X" "Persists Via" "Datasource Y". This defines a specific dependency that can go from one type to another with some attached metadata.
Relationships types defined by plugin developers
Relationships between resources may be defined during the discovery process and/or added/updated later by plugin component
Relationships may be alterable by server-side APIs for informational relationships
Permissions system for relationships respects basic resource RBAC
Dependency Definition:
Source Type
Source Cardinality
Name
Type (enum { dependency, composition, association, generalization })
Target Type
Target Cardinality
Some relationships, especially those within a single plugin would be quite feasibly discovered by the plugin though it may be somewhat complex for that information to be easily exposed to the core inventory model. Other types of dependencies would be higher or system dependencies created and managed through the UI or APIs.
Entities:
Column |
Type |
FK |
Notes |
Changable? |
ID |
number |
|
surrogate key |
No |
PLUGIN |
varchar 100 |
|
Composite key along with name. Unique per plugin. |
No |
NAME |
varchar 255 |
|
Composite key |
Yes |
CARDINALITY |
number |
|
enum {one:one, one:many, many:many} |
Yes |
SOURCE_TYPE_ID |
number |
rhq_resource_type:id |
The unique ID of the source resource type |
No |
TARGET_TYPE_ID |
number |
rhq_resource_type:id |
The unique ID of the target resource type |
No |
SOURCE_CONSTRAINT |
number |
|
enum { CASCADE_DELETE, NONE } |
Yes |
TYPE |
VARCHAR 50 |
|
Relationship concept type: { dependency, composition, association, generalization } |
Yes |
USER_EDITABLE |
boolean |
|
Whether the relationships of this type can be edited by the user |
Yes |
Column |
Type |
FK |
RELATIONSHIP_TYPE_ID |
number |
rhq_relationship_def:id |
SOURCE_RESOURCE_ID |
number |
rhq_resource:id |
TARGET_RESOURCE_ID |
number |
rhq_resource:id |
CTIME |
number |
|
MTIME |
number |
|
Column |
Type |
FK |
RELATIONSHIP_TYPE_ID |
number |
rhq_relationship_def:id |
SOURCE_RESOURCE_ID |
number |
rhq_resource:id |
TARGET_RESOURCE_ID |
number |
rhq_resource:id |
START_TIME |
number |
|
END_TIME |
number |
|
When a relationship definition is deleted, all relationship assignments of the deleted definition should be deleted.
When a resource is deleted, all assignments for the deleted resource(both as source or target) should be deleted.
Modifying a relationship definition is possible but restricted for critical changes such as the resource type IDs,
Allowing changes to the resource type IDs will result orphan relaitonship assignments and other difficulties,
Please see the column "changeable?" on the "RHQ_RELATIONSHIP_DEF" table above whether each column can be modified or not.
This is relevant for both plugin descriptor relationship definitions and API definitions.
[TODO: Describe what happens in case CARDINALITY/TYPE properties change]
Any new created relationship assignment will be audited in the relationship history with an assignment start time.
Any modified relationship assignment will be audited with the new assignment values, an 'end time' assignment will be modified to the current
relationship assignment entry.
[TODO: Define how to audit a removed assignment]
The user must be authorized to load resources on both sides of the relationship otherwise an Access denied exception should occur,
The user must have the 'relationship' permission to add/modify relationships.
Authorization process should be applied to any API calls.
Relationships will /not/ be fail-fast.
If one plugin or a resource type is missing for some relationship definition then deployment process will continue and plugins will still be deployed but the failed relationship will not be be available creation.
An error should be reported in case of a wrong relationship definition recognition.
<relationships> <relationship name="Persists On"> <source type="JMQ JMS Queue" cardinality="one" unique="true"/> <target type="Datasource" cardinality="one"/> </relationship> <relationships>
<relationships> <relationship name="Utilizes" userEditable="true"> <source type="Stateless Session Bean" plugin="JBossAS" cardinality="one" unique="true"/> <target type="*" cardinality="many"/> </relationship> <relationships>
Sometimes it is required to define new relationships via API calls, in cases where the relationships are not known ahead,
This might happen in situations when a relationship definition is based on some logic and should be defined during an evlauation of a process.
The relationship service exposes all the APIs to define and manage relationship definitions. (Please see "APIs" section below)
Well modeled dependencies would allow for modeling failure scenarios (e.g. App X depends on web service Y so when that web service goes down we can alert that a dependency is broken and probably App X is not fully working).
Additionally this relationship information can be used to track important business information. For example, a cluster in staging is related to the production cluster for the same application. Tying them together could make it easier to know that they should be compared during production pushes.
Method |
Description |
Set<Relationship> findRelationshipsByResource(Subject, Resource) |
Look up the currently known relationships for a resource |
Set<Relationship> findRelationshipsByResources(Subject, Resource, Resource) |
Look up the currently known relationships between two resources |
Set<Relationship> findRelationshipsByCriteria(Subject, RelationshipCriteria) |
Find relationships by search criteria |
void addRelationship(Subject, Relationship) |
|
void removeRelationship(Subject, Relationship) |
|
void updateRelationship(Subject, Relationship) |
|
Method |
Description |
RelationshipDefinition findRelationshipDefinitionById (Subject, Long resourceDefinitionId) |
Find a relationship definition by Id |
RelationshipDefinition findRelationshipDefinitionByName (Subject, String name) |
Find a relationship definition by name |
Set<RelationshipDefinition> findRelationshipDefinitionsByCriteria(Subject, RelationshipDefinitionsCriteria) |
Find relationship definitions by search criteria |
void addRelationshipDefinition(Subject, RelationshipDefinition) |
Persist a new relationship definition |
void modifyRelationshipDefinition(Subject, RelationshipDefinition) |
Update a relationship definition, an exception occurs in case restricted properties are modified. |
void removeRelationshipDefinition(Subject, RelationshipDefinition) |
Remove a relationship definition including all relationship assignments of the deleted relationship definition |
Plugin Modeling of Dependencies
Can detect local (single agent) resource relationships
(Possible to detect between plugins?) Probably don't have the inventory APIs necessary
Perhaps limit to parent-child hierarchy?
User Modeling of Dependencies
A user wants to declare that this app is dependent on a database on another box. As a dependency-type relationship, if the database is down, the app will show up as degraded in the UI.
ServerSide Plugin Modeling of Dependencies
Could be used to create and maintain general resource relationships. Listen for resource inventory events and track changes. Use server-side logic to model network relationships.
Could be specific to a plugin type... e.g. tracking and modeling app server "clusters" across agents